HFS File Structure
Volume Number: 1
Issue Number: 12
Column Tag: Ask Prof. Mac
HFS File Structure Explained 
By Steve Brecher, Software Supply, MacTutor Contributing Editor
Anonymous Questions
Q. I know you like to give credit to readers who send questions. But if I prefer
that you not identify me, will you honor my request?
A. Yes. In particular, don't be afraid to ask "dumb" questions!
DS versus DC
Q. Loftus Becker of Hartford, CT asks how one should choose between DS and DC
for data storage in assembly-language programs. Is it a question of style, or are there
reasons of substance to use sometimes one, sometimes the other?
A. The MDS Assembler DS directive reserves global variable storage that the
program will address with an offset from the A5 register. The linker calculates the
offset of each variable declared with DS, and substitutes the offset where you use the
symbolic name of the variable. The linker also puts the total size of the global area
into the CODE 0 resource, so than the Segment Loader can allocate sufficient space
"below A5" when the application is started. DS stands for "define storage.
The DC directive allocates static space within your code segment, at the place
where the directive appears. The assembler will generate the value(s) given as
arguments to DC, which stands for "define constant." DC provides a way to assemble
arbitrary data instead of instructions. The assembler generates PC-relative addressing
for references to DC data.
DS global storage is not initialized when the application is loaded; DC data is
initialized.
DS variables may be directly written with a MOVE instruction, e.g.,
Move #1234,MyDSVar(A5)
DC storage cannot be the direct destination of a MOVE instruction, because the
68000 does not allow the PC-relative addressing mode for the destination of a MOVE.
To alter DC data, its address must first be placed in a register, and then it can be
written to using register indirect addressing, e.g.,
Lea MyDCData,A0
Move #1234,(A0)
DS storage is always resident while your application is running. DC data is local
to the segment in which it is assembled, and goes away if the segment is purged.
DS storage does not use disk space within your application file; DC storage does
take up disk space.
In sum, DS is best used for program variables, while DC is best used for
constants.
SFGetFile Unmounts
Q. I'm writing a desk accessory that shows information about all online volumes.
It also allows the user to change file attributes. I've noticed that sometimes when I put
up an SFGetFile dialog box to allow the user to choose a file, after SFGetFile returns my
DA does not show all the volumes that were there (in the VCB queue) prior to the
SFGetFile. Why?
A. One of the last things SFGetFile does after the user clicks Open or Cancel is to
unmount any online volume that is not in a drive. I'd guess the reason it does this is to
avoid cluttering the VCB queue (list of online volumes) with disks that the user
inserted and then ejected while the SFGetFile dialog box was up. A user searching for a
file could possibly insert and eject a large number of disks. SFGetFile's volume purge
routine does not discriminate among offline volumes which were mounted previously
and those which were mounted while its dialog was active.
PRECs: Correction
In an answer last month, the format of a PREC resource was given incorrectly. A
PREC resource specifies a selection of printer paper sizes. The correct format is:
n [1-word count] -- number of active paper sizes
6 pairs of words -- vertical,horizontal paper size in 120ths of an inch
6 Pascal-format strings -- names of paper sizes
The first word of the resource is a count ranging up to 6 of the number of paper
sizes that are "active," i.e., meaningful. The first "count" pairs of size words and the
first "count" names are "active"; the remaining pairs of size words and name fields, if
any, are unused.
SystemTask within DA
Q. If some code in a Desk Accessory is time-consuming, can a call to SystemTask
be placed in it? I have tried doing this with no apparent harm, but I'm concerned about
re-entrancy problems.
A. SystemTask is a routine generally called in the main event loop of
applications as a "courtesy" to desk accessories and device drivers that need to have
their Control routines entered at periodic intervals. A DA or driver indicates such a
need by setting the dNeedTime bit in the flags word in its header.
SystemTask uses a semaphore variable in low memory to enable it to ignore
recursive calls to itself. Also, it will not generate a Control call to a driver that is
currently executing. So calling SystemTask from within a DA or driver should be OK,
and you needn't worry about re-entrancy because of it.
HFS Preview
We temporarily interrupt our Q&A format to bring you a preview of HFS, the
new Hierarchical File System that is being delivered with Apple's 20MB disk.
Third-party disk vendors either have already implemented or are working on HFS
compatibility.
HFS -- known as TFS (Turbo File System) prior to release -- replaces MFS,
the original Macintosh File System. It is, in effect, a new File Manager. Along with it
comes a new Finder. However, Apple has gone to great pains to make the new system
upwardly compatible with existing applications and existing disks. All MFS file
system calls are supported, and HFS can handle MFS disks.
HFS implements true nested subdirectories in the file system itself. Under MFS,
a pseudo-subdirectory scheme was simulated by Finder folders -- but only within
Finder, and at great expense in Finder execution time. Under HFS, the Finder's desktop
looks much the same, but now the folders are real subdirectories. The new Finder
does have an addtional cosmetic command in the View menu, "by Small Icon," that
causes files to be identified by reduced-size icons with the filename to the right of each
(see Figure 1). This option permits many more files to fit within a given Finder
window; it's available for MFS disks as well as HFS disks.
With HFS, it's no longer necessary to partition hard disks into pseudo- volume
subsets. Instead, users can arrange their files into folders (directories) so that many
files -- thousands -- can co-exist manageably on one disk volume. Directories can
contain directories as well as files, making for a tree file-catalog structure. Two or
more files on a disk can have the same name, as long as each is in a different directory.
HFS also uses a different scheme to allocate and keep track of used/unused space
on a volume so that the minimum file allocation size can be smaller -- 0.5K, as
opposed to 1K for MFS floppies or 2K-4K or more for MFS hard disks. Thus more
small files can fit on a disk.
The biggest change the user will see is in the new SFGetFile and SFPutFile dialogs.
Figures 2-4 show typical SFGetFile displays of the same disk whose Finder view is
shown in Figure 1. In Figure 2, the user sees the folders (and files, but there are none
in the example) of the volume's root directory. He opens Folder 1, and then sees the
dialog box shown in Figure 3. Folder 1 in this example also has only folders within it,
although it could contain files. The user opens Folder 2a, and sees the dialog shown in
Figure 4 which displays the four files and one folder that are the contents of Folder 2a.
The user still hasn't located his file, and he wants to go back up the directory tree. He
clicks on "Folder 2a" on top of the scroll box, and gets a pull down menu of all the
directories he has traversed back through and including the root (which has the same
name as the volume). By dragging the mouse down and releasing, just as for a normal
menu, the user can go back to any of the higher-level directories -- he isn't limited to
going back one level at a time.
The SFPutFile dialog box (not shown) has a new scroll box, like SFGetFile's, in
addition to the TextEdit item for entering a file name. It works like SFGetFile's, but it
shows only folders (directories), not files, since its only purpose is to enable
navigation among directories before specifying the name of a new file to be created.
Now let's turn to the programmer's view of HFS.
Each element of the file system catalog tree -- each directory or file -- is called
a Catalog node (Cnode). The directory at the base of the tree is called the root, and has
the same name as the volume. Intermediate nodes in the tree are always directories;
terminal (leaf) nodes -- those with no branches extending from them -- are either
empty directories or files.
Each Cnode has a name (such as "MacPaint Documents Folder" or "Letter to
Birks, Druffey, & Co."). Cnode names are strung together, with colons in between, to
form a pathname. Each element of a pathname except the last must be a directory; the
last may be either a directory or a file. A full pathname starts with the root directory
name, and describes an arbitrary path to a given Cnode; for example:
My HFS Disk:Folder 1:Folder 2a:Sources:Foo
A partial pathname is one that either starts with a colon or that consists entirely
of a single name, e.g,
:Folder 2a:Sources:Foo
Foo
An empty pathname element -- a pair of colons -- signifies a move up the tree,
i.e., it stands for the parent of the current location. Example:
My HFS Disk:Folder 1:Folder 2b::Folder 2a:Sources
Three colons signifies a move up two levels, four colons up three levels, etc.
Internally, each directory CNode has an identifying number -- a DirID. Cnodes
can be identified to HFS system routines by using a partial pathname, together with a
DirID that denotes a directory from which the partial pathname specifies a path to the
desired Cnode. Note that full pathnames may in some cases exceed 255 characters in
length and thus might not be respresentable as Pascal-format strings.
By using the new file system call OpenWD, the programmer can specify a
working directory. The call returns a WDRefNum which can be used in subsequent
calls to identify a Cnode. WDRefNums are negative, like VRefNums, but their values
won't overlap those of VRefNums. When a WDRefNum is passed to a file system routine
in place of a VRefNum, the system will look up the volume and the directory from the
associated Working Directory Control Block (WDCB) that was filled in by an OpenWD
call. The system creates a fixed pool of WDCBs at startup, and maintains its contents;
the programmer need not be concerned with WDCBs directly.
The working directory scheme is one of the keys to compatibility with MFS.
Under HFS, SFGetFile might return a WDRefNum in its reply record in the field in
which it returns a VRefNum under MFS. If the program then passes that value to an
_Open call, the desired file will be opened; the program needn't be conerned about nor
know whether SFGetFile returned a WDRefNum or a VRefNum.
Existing programs that pass volumename:filename strings to the File Manager
rather than using VRefNums will not be able to access HFS files (except those that are
in the root directory). This includes programs written in C which use stdio routines,
since those routines take only a string as a file identifier. (Specifically, it includes
the programs in the MDS package.) Such programs can be fixed by inserting a call to
SetVol between the call to SFGetFile and the call to fopen(). If SetVol is passed a
WDRefNum, it will set the default directory as well as volume. If permanently
changing the default volume/directory is not desireable, the previous default can be
obtained first via GetVol, and restored after the fopen() with another SetVol. C stdio
programs written in this way will work under both MFS and HFS.
Memory structures such as the Volume Control Block (VCB) and File Control
Block (FCB) have expanded. However, all the new information is in the expansion, so
that programs which access these structures under MFS will still find the old fields in
the same place. Existing programs that access the FCB buffer -- which is an array
rather than a linked list -- won't work, however (Apple has been warning developers
of this for some time).
As mentioned, the existing MFS File Manager calls are all supported under HFS.
In addition, there are some new File Manager routines. Some of the new routines are
extensions of the old ones which return additional information -- HFS-specific fields
-- in expanded I/O parameter blocks. Other new routines are similar to their MFS
counterparts except they accept an additional DirID field in the parameter block. The
rest of the new routines have no MFS counterparts; e.g., a routine to move a file or
directory from one directory to another on the same disk (does not physically move the
file, only changes the catalog); and the routines which open, close, and interrogate the
contents of WDCBs. The File Manager changes will be documented in a new chapter of
Inside Macintosh to be available soon (if not already available by the time you read
this).
The initial release of HFS is RAM-resident in high memory. The final release is
expected to reside in the new ROM (Rumored-Only Memory). HFS takes up additional
system heap space (e.g., for the WDCB pool and an enlarged trap dispatch table); and
the initial RAM version uses even more system heap space for system patches. The
system heap is larger, but even so it's relatively cramped; system heap hogs beware.